The present invention relates to computer systems and more particularly to an adapter for allowing a source application running on one computer system to interact with different target applications running on the same or other computer systems
When the programmable computer industry was in its infancy, any application program (application) was written to run on a single computer. The application executed almost in isolation with its contact with the outside world being limited to receiving data entered by an operator working at a local terminal and to providing results to the operator on a computer monitor and/or as data listings. The application was written and usually monitored by one or more skilled programmers
As the industry matured, skilled programmers continued to write the applications while program or system administrators having a lower level of programming skills assumed the responsibility of running applications in a production (non-development) environment. At around the same time, application owners came to realize that applications did not need to run in isolation and that significant benefits could be achieved by allowing a first application (a source application) to communicate directly with a second application (a target application).
While the skills of application programmers were required to make sure the source application and the target application worked well together, interoperability was not a major problem as both the source application and the target application were typically owned by the same entity and were developed and/or maintained by the same set of application programmers.
As the industry matured even further, application owners then began to realize that if they benefitted from having their own source applications and target applications interoperate to perform complete transactions, they could benefit even more from having their source applications interoperate with target applications belonging to others and running on other, remote computer systems. For example, a company having an inventory control application might want that application to interact directly with a product fulfillment applications owned by its supplier, eliminating the need for written purchase orders, order acknowledgments, shipping documents and invoices as well as the need for employees whose jobs consisted of creating and processing such documents.
Since applications written for different companies are typically written by different application programmers who make their own assumptions about the most appropriate environment and communications requirements for their own application, the problem of assuring interoperability between a given source application and a given target application became greater, the services of skilled application developers were needed to modify the source application code or to write an interface program linking the source application and target application. Regardless which approach was taken, the application developers also have to be called back whenever the source application or target application was enhanced or replaced.
The existing problems were exacerbated when application owners needed to run their single application with the multiple target applications, usually owned by different companies and written by a different set of developers under specific sets of assumptions as to program environment and communications requirements. For example, the owner of the inventory control application might want that application to interact with a product fulfillment applications owned by a number of competing suppliers.
Requiring that skilled application developers be used every time it is decided that a given source application should interoperate with a new, different target application or every time a change is made in the existing source and/or target applications creates serious problems for the application owners.
For one thing, unlike the early days, application programs are now seldom written by developers employed by the companies who execute the programs. Application programs are now typically written by developers working for software companies. When they are available, they are expensive and are available on their employer's schedule, which may or may not be suitable for the application owner's needs.
Finally, while the problems with the prior art have been discussed from the viewpoint of the application owners, it should be recognized that developers of the source applications have to contend with their own problems resulting from a need for source applications which will work in a wide range of business environments and with a wide range of target applications.
The foregoing discussion assumed a situation where a source application had already been acquired and put into use before the owner discovered the need to have that source application interoperate with a different target application. Where a potential licensee for a source application has yet to acquire it, his initial expectation is that the source application developer has the obligation to solve the problem of providing source application code that will work with multiple, some even-not-existent, target applications.
For competitive reasons, source application developers would like to accommodate the potential licensee's expectation. However, the expense of developing application code to assure interoperation with multiple target applications, is a real burden for the source application developer, particularly if the licensee expects the developer to update the code to achieve interoperability with new target applications.